home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13583 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB
  1. Path: news.csuohio.edu!usenet
  2. From: jabaker@grail.cba.csuohio.edu (jason)
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.object,comp.software-eng
  4. Subject: Re: Pointers are hacks in c++ (portablity hackers etc)
  5. Date: 26 Mar 1996 11:37:24 -0500
  6. Organization: Citizens for a Better Danza
  7. Sender: jason@jlbaker.async.csuohio.edu
  8. Message-ID: <vraufu7y2.fsf@jlbaker.async.csuohio.edu>
  9. References: <4ikb6kINN1is@mayne.ugrad.cs.ubc.ca> <DoI5Ao.AyJ@assip.csasyd.oz>
  10.     <4j7kuf$2ur@news4.digex.net>
  11. NNTP-Posting-Host: jlbaker.async.csuohio.edu
  12. In-reply-to: ell@access4.digex.net's message of 26 Mar 1996 02:31:43 GMT
  13. X-Newsreader: Gnus v5.0.13
  14.  
  15. In article <4j7kuf$2ur@news4.digex.net> ell@access4.digex.net (Ell) writes:
  16.  
  17. > jason (jabaker@grail.cba.csuohio.edu) wrote:
  18. > : [ways to delete and keep track of objects elided]
  19. > : So, there are two questions.  How was next allocated -- this can be
  20. > : solved by ensuring that next always comes from the heap.  
  21.  
  22. > 'next' should _never_ be a 'local' stack based structure.
  23.  
  24. Thanks, "'next' should _never_ be a 'local' stack based structure." is
  25. much clearer than "ensuring that next always comes from the heap."
  26.  
  27. C++ has a complicated mechanism to allow objects to live in the stack,
  28. heap or bss.  Are you suggesting I build my own mechanism on top of it
  29. to ensure that objects only live on the heap?  I could make a class's
  30. constructor protected and define a static 'newor' method to create new
  31. objects.  But, at this point I am fighting the language and I might as
  32. well start overloading arithmetic operators for IO.
  33.  
  34. > : And, does
  35. > : anything else refer to next -- this can't be solved with a reference
  36. > : count, we are dealing with a linked list of arbitrary length, it can
  37. > : only be solved by ensuring that there are no other references.
  38.  
  39. > I don't see how reference counting heap based objects, which register 
  40. > themselves in a central place, does not allow effective gc in C++.
  41.  
  42. I'm not sure what you mean by "objects which register themselves in a
  43. central place," but is is very clear to me that you cannot maintain
  44. reference counts on list cells.  Let's say you are using a list as a
  45. stack.  A function f1 creates a non-empty stack, and passes it to f2.
  46. f2 pushes things onto it and passes it to f3.  f3 pushes more things
  47. onto it.
  48.  
  49. The list might look like this:
  50.  refcnt == 1      refcnt == 2      refcnt == 3
  51. |...f3's cells...|...f2's cells...|...f1's cells
  52. ^f3's list       ^f2's list       ^f1's list
  53.  
  54. Each time a new list object is created, the reference count on each
  55. cell accessible from it must be incremented.  Imagine what happens
  56. when the compiler starts generating temporary list objects.  
  57.  
  58. I have more problems with reference counts.  What happens to the
  59. reference count of a member object?  At best it just sits there taking
  60. up space, and at worst (it is a public member which someone has taken
  61. the address of), references to the member must show up in the
  62. reference count of the containing object.  (Automatic garbage
  63. collection in c++ would face the same problem.)  Furthermore, objects
  64. on the stack or bss should have refcnt >= 1 for their entire lives,
  65. yet c++ does not provide a way for an object to determine how it was
  66. allocated.
  67.  
  68. Jason
  69.